You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
github_actions: pass home hostname to gh-actions-lock - #16504
Pass the repository's home host to gh-actions-lock so lockfile relocks stay correct with the hostname-aware CLI (github/gh-actions-lock#137).
The CLI binds every pin with an omitted lockfile hostname to its home host. Core runs it in a temp dir with no git remote, so the home host silently defaults to github.com.
Accept v0.0.3. The CLI migrates v0.0.2 and always writes v0.0.3.
Report host-identity 404s as user errors. The CLI wraps every lookup error in "verifying repository identity", so 5xx, rate-limit 403s and timeouts stay EngineError and retry.
Bind pinned actions to their lockfile host (omitted means the home host) instead of probing the tenant. The probe falls back to github.com on any failure, so a tenant blip would otherwise rebind an in-tenant action to github.com.
Fetch and relock actions.lock for *.ghe.com sources under the existing github_actions_lockfile experiment, same as github.com. dependabot-api already sends it from the repo flag dependabot_github_actions_lockfile, so no API change is needed.
Anything you want to highlight for special attention from reviewers?
Draft for staging only. The Dockerfile temporarily builds the CLI from source at c5ee15d, because no release exists for that SHA yet. It moves back to a release pin before review.
How will you know you've accomplished your goal?
Staging dry-runs against existing lockfiles. Relocks should keep the right host binding and write v0.0.3.
A FileUpdater spec checks that source_hostname: "tenant.ghe.com" reaches CliEngine.new(credentials, hostname: "tenant.ghe.com"). Parser specs keep an omitted-hostname pin on the home host while the tenant returns 503, and send an explicit github.com pin to github.com without probing the tenant. A CliEngine spec maps a transient 502 to EngineError.
Checklist
I have run the complete test suite to ensure all tests and linters pass.
I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
I have written clear and descriptive commit messages.
I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
I have ensured that the code is well-documented and easy to understand.
Builds github/gh-actions-lock#137 at c5ee15d from source; no release
exists for this SHA. Swap back to a release pin before review.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
The engine binds every pin with an omitted lockfile hostname to its home
host. It runs in a temp dir with no git remote, so without --hostname
the home host silently defaults to github.com. Pass --hostname from the
job source and forward only a home-host token. Accept the v0.0.3 schema
the engine now writes, and report lock host-identity failures as
user-actionable rather than engine errors.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Fetch actions.lock for *.ghe.com sources under the existing
github_actions_lockfile experiment, same as github.com.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Error mapping (lockfile/cli_engine.rb:32): upstream, verifying repository identity also wraps transient errors such as 5xx, 429 and timeouts. Please make sure those don't surface to users as dependency_file_not_resolvable.
Deleted workflows (file_updater.rb:85): relocks are scoped to the changed workflows, so pins for removed workflows can stay in the lockfile. On Proxima, VerifyHosts checks every pin. Please confirm that a stale pin can't fail every relock.
Lockfile hostname (file_parser.rb:139-146): the parser resolves tenant-first and doesn't read the pin's hostname, while the CLI does. Please confirm this is OK for now, or track it as a follow-up.
Lockfile format: relocks write v0.0.3, which older CLI versions (v0.1.6) reject. Please make sure users have a compatible CLI before prod.
If we want to do dry-run for proxima
bin/dry-run.rb doesn't pass source_hostname, so Proxima dry-runs default to github.com.
CI: the nuget and pip-compile failures are unrelated.
gh-actions-lock wraps every RepoIDs error in 'verifying repository
identity', so 5xx, rate-limit 403s and timeouts were surfacing as
dependency_file_not_resolvable instead of retryable engine errors.
A pinned action now uses the host recorded in the lockfile (omitted
means the home host) instead of probing the tenant and falling back to
github.com on any failure.
`$/` composites can live anywhere in the repo and call each other, so the
engine needs every action.yml/action.yaml at its repo-relative path. Fetch
them with one recursive tree call when a workflow uses `$/` and the lock
exists, and name the temp dir as the repo root via GH_ACTIONS_LOCK_REPO_ROOT.
This compares the entire lock key case-insensitively, but Git refs are case-sensitive. A pin for owner/repo@Release can therefore supply the hostname for owner/repo@release, even though those may resolve to different refs. It also raises on a syntactically valid malformed lock with a non-string dependency key. Compare only the repository portion case-insensitively and the ref exactly, while ignoring non-string keys.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What are you trying to accomplish?
Pass the repository's home host to
gh-actions-lockso lockfile relocks stay correct with the hostname-aware CLI (github/gh-actions-lock#137).The CLI binds every pin with an omitted lockfile
hostnameto its home host. Core runs it in a temp dir with no git remote, so the home host silently defaults togithub.com.--hostname, taken from the job source.v0.0.3. The CLI migratesv0.0.2and always writesv0.0.3.EngineErrorand retry.actions.lockfor*.ghe.comsources under the existinggithub_actions_lockfileexperiment, same as github.com. dependabot-api already sends it from the repo flagdependabot_github_actions_lockfile, so no API change is needed.Anything you want to highlight for special attention from reviewers?
Draft for staging only. The Dockerfile temporarily builds the CLI from source at
c5ee15d, because no release exists for that SHA yet. It moves back to a release pin before review.How will you know you've accomplished your goal?
Staging dry-runs against existing lockfiles. Relocks should keep the right host binding and write
v0.0.3.A
FileUpdaterspec checks thatsource_hostname: "tenant.ghe.com"reachesCliEngine.new(credentials, hostname: "tenant.ghe.com"). Parser specs keep an omitted-hostname pin on the home host while the tenant returns 503, and send an explicitgithub.compin to github.com without probing the tenant. ACliEnginespec maps a transient 502 toEngineError.Checklist